One gap worth checking before tagging: the release branch looks stale relative to main.

The release head (663b034b) was cut from #3566, but origin/main is now at #2864 — fix(shell): validate command names and tighten install/uninstall detection, which merged after the cut. Since the release skill's step 1 (git merge --ff-only origin/main) wasn't applied here, #2864 isn't in the changelog — yet it'll ship in the 0.69.1 binary anyway, because /gpk squash-merges onto whatever main tip exists and the tag lands on that squash commit (which contains #2864). Net effect: a user-facing shell-integration fix ships undocumented — exactly the "cutting from a stale branch silently drops everything merged since" case step 1 warns about, in its documentation-drift form.

Two ways to reconcile:

• Fast-forward the release branch to origin/main and add a ### Fixed entry for #2864 (it's three distinct shell-integration fixes: command-name validation, duplicate-line detection on install, and cmd-agnostic uninstall scanning — clearly changelog-worthy), or
• If #2864 is meant to wait for 0.69.2, that's fine — but then confirm the tag won't be placed on a main commit that already contains it.

Everything else checks out: Cargo.toml/Cargo.lock both move 0.69.0 → 0.69.1; the four cited PRs (#3561, #3557, #3566, #3564) match their descriptions; moving #3566 out of the 0.69.0 SignPath line into the new 0.69.1 double-zip entry is correct; and omitting the #3548 refactor and #3563 docs-only commits is reasonable. Flagging rather than blocking — the tag placement is the maintainer's call.